Benchmark Results

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

Interesting. The remaining errors with the SimpleMesh tests are invalid barycentric coords errors from integrating Triangles.

Still debugging. One of the remaining issues (UndefVarError: geometry not defined) has a stack trace that appeared at first to be throwiing directly from combinations.jl:138's use of geometry, but I've done some debugging and it appears to be coming from some other function further along the stack.

Edit: got it. There was a holdover in the default rule selection for the integral(::Domain) method.

I've run some tests locally to figure out why the Meshes.CartesianGrid test set takes so long, and I've run across some odd results.

• The test set initially took about 80 minutes to run on my computer.
• I ran some tests in a separate REPL and couldn't find any obvious slow integration. Then I tried adding some Logging.@debug lines to give me a quick trace on where the tests are spending all of their time, and suddenly it would repeatably run in about 15 seconds.
• I manually reverted my local repo state to the current commit to make sure there wasn't some unnoticed change and then I rebooted VS Code. Re-running the test set, the first run took about 12 minutes, but then successive runs took 10-15 seconds.

Based on a little more debugging, even in the longer CartesianGrid runs the actual runtests function only requires 10-15 seconds, so I suspect that TestItems is also measuring compilation time and that must be dominating the first runtime in this case. Odd that it only seems to be an issue here and not also for RegularGrid. Maybe some kind of type instability/inference issue?

I had a vague suspicion that turned out to be true. The really extreme CI times were nearly 100% compilation time. The output of elements(discretize(geometry)) is a generator, so I wondered if additionally collecting this array before integration would simplify things for the compiler at the cost of a single small additional allocation. Based on the new CI times this seems to have worked.

@juliohm Should Meshes.GeometryOrDomain be exported? This PR currently triggers a CI fail (ExplicitImports.jl) over importing it as a non-public/exported reference. I can always just define it locally if it wasn't intended for stable external use.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (5c7a06e) to head (4e7c1cd).
Report is 1 commits behind head on main.

@@            Coverage Diff            @@
##              main      #182   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           18        19    +1     
  Lines          181       190    +9     
=========================================
+ Hits           181       190    +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I accepted the suggestions but had to reformat the _default_rule definition to avoid exceeding our max line length formatting rule.